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ABSTRACT 



A computer-implemented vault centrally archives an appli- 
cation from a client. Each application may be formed from 
one or more files, and each application has a unique meta 
description for reconstructing the application using the one 
or more files. The vault has one or more files which may be 
shared among applications; an access controller for allowing 
the client to retrieve a file from the vault based on the meta 
description; and a post controller for allowing the client to 
store a single instance of a uniquely indexed file based on the 
meta description. 

21 Claims, 7 Drawing Sheets 
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SOFTWARE VAULT 

BACKGROUND 

Inexorable advances in electronics have led to widespread 
deployment of inexpensive, yet powerful computers that are 
networked together. Over time, programs installed on these 
computers are updated and these updates need to be main- 
tained. Information system departments and their users face 
the thorny task of maintaining numerous instances of soft- 
ware across their complex distributed environments. The 
maintenance process covers a number of tasks, including 
software installation, synchronization, backup, recovery, 
analysis and repair. 

A detailed knowledge of a computer's dynamic environ- 
ment and its system configuration is needed in the mainte- 
nance process to prevent situations where modifications to 
one component may introduce problems in other compo- 
nents. Moreover, an accurate knowledge of the system's 
configuration is required to verify compatibility and to 
ensure integrity across multiple operating environments and 
across diverse processors. Software applications can have 
numerous components and dependencies and, in a modern 
network with diverse processors and peripherals, the range 
of possible configurations can be staggering. 

Historically, relationships between software components 
have been manually detected and component states have 
been recorded in a log. This state information is external of 
the components themselves and must be updated whenever 
the components change. As state information is recorded 
only at the time of installation, changes made subsequent to 
installation may be lost. As the rate of change increases and 
complexity of the software configuration grows, the external 
state representation becomes difficult to maintain and prone 
to error. Moreover, during normal operation, users may 
make changes to the software through individual personal- 
ization and through the installation of additional software, 
thus changing the state information. The difference in state 
information between software installation and software 
operation can lead to unpredictable behavior and may 
require support from information system personnel. 

SUMMARY OF THE INVENTION 

In one aspect, a computer-implemented vault archives 
software components, where only a single instance of each 
component that is multiply-used is stored in the vault. The 
vault includes unique instances of the one or more software 
components and an access controller for performing a direct, 
random access retrieval of the one or more software com- 
ponents from the vault. 

Implementations of the invention include one or more of 
the following. The access controller generates a unique key. 
The unique key may be used to access a software compo- 
nent. The unique key may be generated from a persistent 
metadata description. A post controller may perform a direct, 
random access insertion of a software component to the 
vault. The post controller may generate a unique key from 
the new component and optimizes storage if the unique key 
exists. A look-up controller may perform a direct, random 
access determination of the existence of a software compo- 
nent in the vault. A client may be coupled to the vault, the 
client having a physical software component residing on the 
client, the client generating a key from the physical software 
component. One or more secondary vaults may be coupled 
to the vault with a fault-tolerant rollover system for sequen- 
tially searching each vault for the presence of a target 
software component. The secondary vaults may be ordered 
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based on accessibility of the vaults. A client may generate a 
key and apply the key to recover the target software com- 
ponent from the most accessible of the vaults. The client 
may use a metadata description to generate the key. If the 

5 search of a determined vault fails to locate the target 
software component, the client may skip the determined 
vault and modify the search order of the vaults in recovering 
the target software component. 
In a second aspect, a computer-implemented vault 

10 archives software components, where only a single instance 
of each component that is multiply-used is stored in the 
vault. The vault includes means for storing unique instances 
of the one or more software components on the vault; and 
access means for performing a direct, random access 

]5 retrieval of the one or more software components from the 
vault. 

Implementations of the invention include one or more of 
the following. The access means may generate a unique key. 
The unique key may be used to access a software compo- 

20 nent. The unique key may be generated from a persistent 
metadata description. A post means may perform a direct, 
random access insertion of a software component to the 
vault. The post means may generate a unique key from the 
new component and optimize storage if the unique key 

25 exists. A look-up means may perform a direct, random 
access determination of the existence of a software compo- 
nent in the vault. A client may be coupled to the vault, the 
client having a physical software component residing on the 
client, the client generating a key from the physical software 

30 component. One or more secondary vaults may be coupled 
to the vault with means for sequentially searching each vault 
for the presence of a target software component. The sec- 
ondary vaults may be ordered based on accessibility of the 
vaults. The client may have a means for applying the key to 

35 recover the target software component from the most acces- 
sible of the vaults. The client may use a metadata description 
to generate the key. If the search of a determined vault fails 
to locate the target software component, the client may skip 
the determined vault and modifies the search order of the 

40 vaults in recovering the target software component. 

In a third aspect, a method for archiving software com- 
ponents where only a single instance of each component that 
is multiply-used is stored in a vault includes: storing unique 
instances of the one or more software components in the 

45 vault; and performing a direct, random access retrieval of the 
one or more software components from the vault. 

Implementations of the invention include one or more of 
the following. The method may generate a unique key. The 
unique key may be used to access a software component. 

50 The unique key may be generated from a persistent metadata 
description. The method may perform a direct, random 
access insertion of a software component to the vault. A 
unique key may be generated from the new component and 
used to optimize storage if the unique key exists. The 

55 method may perform a direct, random access determination 
of the existence of a software component in the vault. A 
client may be coupled to the vault, the client having a 
physical software component residing on the client, the 
client generating a key from the physical software compo- 

60 nent. One or more secondary vaults may be coupled to the 
vault and sequentially searched for the presence of a target 
software component. The secondary vaults may be ordered 
based on accessibility of the vaults. The client may apply the 
key to recover the target software component from the most 

65 accessible of the vaults. The client may use a metadata 
description to generate the key. If the search of a determined 
vault fails to locate the target software component, the client 
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may skip the determined vault and modifies the search order FIG. U is a flowchart illustrating a process for replicating 

of the vaults in recovering the target software component. software components from the vault. 

Advantages of the invention include one or more of the FIG. 12 is a flowchart illustrating an exemplary applica- 

following. The vault can inventory, install, deploy, maintain, tion of the vault in installing software, 

repair and optimize software across local and wide area 5 pj G 13 js a diagram of an exemplary application for 

networks (LANs and WANs). By automating the human- maintaining software using the vault, 
intensive process of managing software throughout its life 

cycle, the vault reduces the total cost of ownership of DESCRIPTION 

computers in networked environments. Users can reduce the FIG. 1 shows a computer system 100 with one or more 

time required for software packaging by simply probing an 10 yaul(s fc shown ^ system 1Q0 has QQe or mofe clients 102 

application for its current state and storing unique instances each of which has a ^ of cata i 0 gs 104, as well as a client 

of components of the software in a vault. Software instal- vault 106 ^ diem vauh 106 ^ a computer rea dable 

lation may then be performed by moving valid working me dium which stores one or more software components 

states from one client machine to another. Further, error (entities) which are designated by the set of catalogs 104. In 

prone installation of the software is avoided, increasing the 15 ^ q ^ {hc yauU 1Q6 cxists qd & ^ gtorage dcvice 

out-of-box success by installing known working software such as a hard drive on the comput er system 100. 

states and insuring against deletion of shared components. Alternatively, the vault may reside on one or more data 

Moreover, the vault can be used to diagnose problems by storage devices connected to a network 110, as discussed 

comparing an existing state on a client computer to both a below. Each of the software components may be referenced 

previously working state and a reference state stored in the 20 by more than one application, and the software components 

vault. Further, the vault can be used to allow applications are used to reconstruct the application, 

which have been damaged to self-heal applications by Each catalog 104 includes metadata which is generated by 

automatically restoring previously working states or rein- determining run-time states of each software application, 

stalling components from reference states. Generally, the metadata for each software application is an 

The vault can also support remote and disconnected users abstract representation of a predetermined set of function- 
by protecting applications on their desktop and ensuring that alities tailored for a particular user during installation or 
software is configured appropriately. The vault can also customized during operation of the software application, 
synchronize user desktops by automatically updating all The metadata is a list pointing to various software compo- 
application components and configuration settings while ^ nents (entities) making up an application software and a root 
still allowing custom settings for the user. The vault also entity which represents an action that may be performed by 
automates custom computer setups/upgrades by providing the user at another machine, place or time, 
replication of working states from client machines. Infer- ^ metadata ^ generated by analyzing the run-time 
mation stored m the vault may be used to provide vital states of the software application and checking the existence 
application information including system values and 35 of the entities and enuty dependencies, which may change 
resource conflicts to help information systems personnel. over ^ ^ hsl of tne eQtities ^ pruned by deleting 

Further, the vault decreases network overhead and overlapping entities and by combining similar entities. In the 

increases scalability of electronic software distribution by grouping of entities in the metadata, an intersection of the 

eliminating delivery of duplicate files that make up software entities is determined such that a package of entities can be 

packages. The flexible architecture of the invention protects 4Q succinctly defined and that all the information necessary for 

user investment in existing solutions for enterprise- wide ft can be represented as the metadata with or without the 

systems management, network management, and applica- actual entities. Enough information about each entity is 

tion management, included in the metadata so that an analysis of correctness 

RRTFF nPSPRTPTTOM OF THF OR AWnsrr*s may be P erformed - The resulting metadata provides indices 

BRIEF DESCRIPTION OF THE DRAWINGS ^ tQ ^ cUent ^ ^ which stQres unique mstances of 

FIG. 1 is a diagram illustrating a system with one or more software components locally to the client 102. 

vaults for communicating with one or more clients. i n addition to the client vault 106, the client 102 may also 

FIG. 2 is a diagram illustrating communications between access remotely stored component files associated with the 

the client and the one or more vaults. catalog 104. To access these remote component files, the 

FIG. 3 is a flowchart illustrating a process for accessing 50 client 102 communicates over the network U0, which may 

software components from the vault. be an intranet, or a wide area network (WAN) such as the 

FIG. 4 is a flowchart illustrating a process for comparing Internet. The network 110 may also be a local area network 

keys in FIG 3 (LAN). Connected to the network 110 are one or more vaults 

FIG. 5 is' a flowchart illustrating a process for posting 1 J 2 ' " 4 ^"'^u °l ^ U ^ 116 j™ 1 ^"* « te 

software components to the vault. 55 of catalogs 11&-120 which are mdices of metadata files that 

__ , . * t -ii . .mi represent the physical components of the software being 

FIG. 6 is a flowchart illustrating in more detail the process "published" for the client 102 

for generating a post key in FIG. 5. m „ , . ' . t . 

° or/ pjQ 2 shows in more detail various communication 

FIG. 7 is a flowchart illustrating a process for performing modules between a clienl m and one or more vaults 

lookup based on an identity key. 6Q 13 o_ 13 2. The vaults 130-132 may be local vaults, remote 

FIGS. 8A and 8B are flowcharts illustrating alternate vaults accessible from a network, or a combination of both, 

processes for software management. i n FIG. 2, an access controller 124 allows the client 122 to 

FIG. 9 is a flowchart illustrating a process for publishing retrieve files from the one or more vaults 130-132. A post 

meta data information associated with the software compo- controller 126 allows the client 122 to place one or more 

nents. 65 files on the vaults 130-132. A lookup controller 128 allows 

FIG. 10 is a flowchart illustrating a process for storing the client 122 to preview and compare catalogs of files 

software components on the vault. stored locally versus files stored on the vaults 130-132. Each 
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of controllers 124, 126 and 128 may be implemented using 
a processor on the client 122 and computer instructions as 
described below. Alternatively, each of controllers 124, 126 
and 128 may be implemented using a processor which is 
located on the network 110. Pseudo-code showing file 
accesses using the access controller 124, the post controller 
126 and the lookup controller 128 is as follows: 

//**** Access Controller 

Pass metadata descriptor 

Transform metadata descriptor into key 

for each vault 

directly access key on vault 
if found then end for 
next 

return full URL and file for key 

//**** Post Controller 

Pass metadata descriptor 

Transform metadata descriptor into key 

for each vault 

directly access key on vault 
if found then end for 
next 

if not found then 

locate first writable vault 

insert file with key 

end if 

return 

//**** Lookup Controller 
Pass metadata descriptor 
Transform metadata descriptor into key 
for each vault 

directly access key on vault 
if found then return full URL 
next 

return not found 

Turning now to FIG. 3, a process 140 for accessing files 
stored on one of the vaults 130-132 is shown. The process 
140 first generates a key from a metadata file (step 142). The 
metadata file identifies all elements that make up a single 
application, as identified using a state probe. The operation 
of the state probe is described in more detail in a copending 
application entitled "Automatic Configuration 
Management," application Ser. No. 08/993,103, filed on 
Dec. 18, 1997, the content of which is incorporated by 
reference. 

The metadata file describes the elements of the 
application, including the location of the files and the 
configuration of the application. The size of the metadata file 
is typically a small fraction of the size of the total state 
referenced. The key from the metadata file may be used to 
access and retrieve component files stored in the vaults 
130-132. 

If the component files of the application software to be 
recreated using the key are large and therefore cumbersome 
to transfer, it is more efficient to determine whether the 
component files of the application software already exist 
locally. Such determination may be made by first looking up 
the key on the client 122 (step 144) and then optionally 
comparing the key generated from the metadata file to the 
key on the client 122 (step 146) and is described in reference 
to FIG. 4 below. The key comparison process sets a flag if 
a difference exists and otherwise clears the flags. 

The difference flag is then checked (step 148). If the 
difference flag is set, the key generated from the metadata 
file is used to retrieve software components files from the 
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vault (step 150). Alternatively, if the flag is cleared, the 
desired file already exists on the client 122 and the process 
140 exits (step 152). Pseudo-code for the process 140 is as 
follows: 

Transform metadata descriptor into key 

Using location attributes of key, locate file on client 

Generate key for local file 

compare metadata key and local key 

if metadata key matches local key then return 

for each vault 

directly access key on vault 
if found then retrieve file 
next 

return success if found 

Turning now to FIG. 4, the key comparison step 146 of 
FIG. 3 is illustrated in more detail. First, the difference flag 
is initialized to zero (step 160). Next, the process 146 
determines whether binary data associated with the files 
being compared are different (step 162). If no difference 
exists, the process exits (step 176). Alternatively, if the 
binary data differ, the process then compares the keys based 
on various sequence attributes associated with each of the 
files being compared (step 164). 

For example, location attributes, defined as directory 
paths, may be checked. Once the location attributes are 
determined to be equal, the sequence attributes may be used 
for further identification. A combination of multiple 
sequence attributes may be used together to reliably deter- 
mine identity. Common examples of sequence attributes 
may include, but are not limited to, attributes such as date 
created, date modified, date last accessed, and version num- 
ber. Certain sequence attributes may take precedence over 
other sequence attributes. For example, if the version num- 
bers are not equal, date attributes may be ignored. 

The process of FIG. 4 checks whether the sequence 
attributes are equal (step 166). If so, the difference flag is set 
(step 168). From step 166, if the attributes are not equal, the 
process checks whether one of the attributes is newer than 
the other (step 170). If so, the process proceeds to step 168 
to set the difference flag. Alternatively, in the event that the 
attribute is not newer, the process then checks whether or not 
one of the attributes is older (step 172). If no, the process 
proceeds to step 168 to set the difference flag. Alternatively, 
in the event that one of the attributes is older, the process 
determines whether or not the file may be overwritten (step 
174). If so, the difference flag is set (step 168). Alternatively, 
the process exits (step 176). 

Referring now to FIG. 5, a flowchart illustrating a post- 
process 180 for placing files onto the vault is shown. The 
post-process 180 first generates a post key from the metadata 
file (step 182). Optionally, the process 180 may look up the 
key present on the vault (step 184) and compare the keys 
(step 186), If the comparison causes the difference flag to be 
set (step 188), the key from the metadata is used to post the 
file to the vault from the client (step 190). From step 188 or 
step 190, the process of FIG. 5 exits (step 191). Pseudo-code 
for the process 180 is as follows: 

Transform metadata descriptor into key 

for each vault 

directly access key on vault 
if found then end for 
next 

if not found then 

locate first writable vault 

insert file with key 

end if 

return 
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Turning now to FIG. 6, the process 182 of FIG. 5 to physical components of the software being published, is 

generate the post key from the metadata file is shown in updated (step 418). Finally, the process 410 exits (step 420). 

more detail. In FIG. 6, metadata associated with each file is Turning now to FIG. 10, the file storing step 414 of FIG. 

generated (step 183). Next, the process 182 verifies the 9 is shown in more detail. Each item in the metadata file is 

integrity of the file (step 185). 5 initially selected (step 432). The integrity of the item is 

Integrity is verified using a sufficiently unique byte level verified (step 434). The metadata information is used to 

check to statistically guarantee that the file is intact. Various verify the integrity of the item. Simple sequence and identity 

known algorithms may be used, including 32-bit checksums, attributes are compared to ensure that no change has 

cyclic redundancy checks, and hash -based functions and occurred to the file. The fastest comparisons are performed 

checksums. While any method which detects a change in the 10 first with slower but more reliable checks being performed 

byte ordering of the file may be used, a method with high later - Bv usin g a combination of attributes which may 

levels of statistical uniqueness and favorable performance include the date accessed, date modified, version number, 

characteristics should be used. For example, MD5 (Ron date created > multiple file checksums, block checksums, 

Rivest, 1992) provides a cryptographically strong check- complete byte comparisons, secure file hashing, and file 

sum attribute comparison, the integrity of the file may be reliably 

a"i™ v i r _ * j * /+ io-i\ 15 correlated to the information in the metadata. 

A key is then generated from the metadata (step 187) Kr A . ., 4 . . A , , 4 

, r / , 10n \ v Next, a unique identification value is generated (step 436) 

before the process 182 exus (step 189). Key generation ^ Qn ^ of ^ fi]e m ^ ^ ^ a \J ch fo { 

should include an integrity ^checksum as described above as a of ^ me fc done {Q determine the existence of lhe 

well as basic information about the size name, and attributes fiIe (stcp m) If me of the file does not exist in lhe 

of the file. In the form of a checksum, the key allows identity 20 vauU? then the file ^ copied into me vault (step 440) From 

information as well as integrity information to be easily step 43s or stcp m thc process of FIG 10 determmcs 

verified. whether additional items remain to be processed (step 442). 

-Himing now to FIG. 7, a process 190 for performing If so> the process of FIG 10 loops back t0 step 432 to 

look-ups based on an identity key is shown. The process 190 con tinue processing the next item. Alternatively, the process 

first enumerates all available vaults in a vault chain (step 25 ex ^ te ^ step 

192). Next, for each vault, the process 190 generates a ^ rep li C ate step 450 of FIG. 8B is shown in more detail 

universal resource locator (URL) based on the vault and the in FIG u First? the source vault ^ located (step 452) Next> 

identity key (step 194). Next, the process 190 checks for the lhe destination vault is located (step 454). Files are then 

existence of the URL (step 196). If the URL exists in step transferred from the source vault to the destination vault 

198, the vault has been located and the process 190 exits 30 ( step 456 y similarly, metadata information is copied from 

(step 202), me 50^,-^ vau i t l0 lne destination vault (step 458). Finally, 

The URL specifies a unique address using one or more lhc vault catalog ^ updatcd ( stcp 460 ) before the process of 

protocols to identify and access local and remote resources. F j G n ^ step 452) 

Alternatively, if the current vault fails to offer the correct Xumiag now t0 F jq n , the installation step 470 (FIG. 

URL, the next vault is selected (step 200) before the process 35 8B) ^ shown m more detail ia FIG u . First, the vault 

190 loops back to step 194 to continue searching all vaults catabg is loaded (step 4?2) Ncxt> tfae higfaest version of the 

in the vault chain. If all vaults have been searched but the software stor ed in the vault is determined (step 474). The 

URL is not found, the process returns with an error indica- met adata associated with the highest version of the software 

tion. Pseudo-code for the process 190 is as follows: ^ to the target machine (step 476) Further? data [& 

Transform metadata descnptor into identity key 40 remap ped (step 478). The process of FIG. 12 then applies a 

Construct redundant vault chain preprocessing operation to the remapped data (step 480) to 

Sort vault chain in order of closest accessibility convert data ^to the proper format and set up variables 

for each vault appropriately, among others. Further, items associated with 

form URL based on vault location and identity key tne software are installed (step 482). A post-processing 

check existence of URL 45 process is applied (step 484), This step is similar to step 480 

if found then return vault location and URL in that variables are checked and data is formatted. Finally, 

next an inventory of the software being installed is updated (step 

if not found then return error 486) before the process exits (step 488). 

FIGS. 8A and 8B show alternate processes to provide Turning now to FIG. 13, the maintenance step 490 of FIG. 

state -based software life cycle management using a vault. 50 SB is shown in detail. The maintenance step 490 is an event 

Turning now to FIG. 8A, a process for performing software driven process and thus receives a software trigger event 

management first generates the metadata (step 403), as (step 492). Based on the trigger event, the process of FIG. 

described in FIG. 1. The information is then used to maintain 13 determines various possible events, including a check for 

software (step 405) before the process exits. update event 494, a protect software event (step 496), a 

Correspondingly, FIG. 8B shows a second software life 55 software recovery (step 498) event, a check removal event 

cycle management process. Initially, the metadata informa- (step 500), and an examine system event (step 502). From 

tion is generated and published (step 410). Next, compo- steps 494-502, the triggering event is reported (step 504) 

nents of the software are replicated (step 450) based on the before the process of FIG. 13 exits (step 506). 

metadata. The software is then installed (step 470). After In the manner discussed above, the vault can inventory, 

installation, the software may be maintained (step 490). 60 install, deploy, maintain, repair and optimize software across 

Turning now to FIG. 9, the metadata publication step 410 LANs and WANs. The vault installs only known working 

is shown in more detail. In FIG. 9, a vault is located (step software combinations and insures against deletion of shared 

412). The vault may be a server that maintains items components, thus protecting user investments in existing 

referenced in the metadata files. Next, component files solutions for enterprise-wide systems management, network 

associated with the software are stored in the vault (step 65 management, and application management. 

414). Similarly, metadata is stored in the vault (step 416). A The techniques described here may be implemented in 

catalog, or an index of metadata files that represent the hardware or software, or a combination of the two. 
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Preferably, the - techniques are implemented in computer 
programs executing on programmable computers that each 
includes a processor, a storage medium readable by the 
processor (including volatile and nonvolatile memory and/or 
storage elements), and suitable input and output devices. 
Program code is applied to data entered using an input 
device to perform the functions described and to generate 
output information. The output information is applied to one 
or more output devices. 

Each program is preferably implemented in a high level 
procedural or object-oriented programming language to 
communicate with a computer system. However, the pro- 
grams can be implemented in assembly or machine 
language, if desired. In any case, the language may be a 
compiled or interpreted language. 

Each such computer program is preferably stored on a 
storage medium or device (e.g., CD-ROM, hard disk or 
magnetic diskette) that is readable by a general or special 
purpose programmable computer for configuring and oper- 
ating the computer when the storage medium or device is 
read by the computer to perform the procedures described. 
The system also may be implemented as a computer- 
readable storage medium, configured with a computer 
program, where the storage medium so configured causes a 
computer to operate in a specific and predefined manner. 

While the invention has been shown and described with 
reference to an embodiment thereof, those skilled in the art 
will understand that the above and other changes in form and 
detail may be made without departing from the spirit and 
scope of the following claims. 

What is claimed is: 

1. A computer-implemented vault for archiving software 
components, where only a single instance of each compo- 
nent that is multiply-used is stored in the vault, comprising: 

unique instances of the one or more software components; 

an access controller for performing a direct, random 
access retrieval of the one or more software compo- 
nents from the vault; and 

a post controller for performing a direct, random access 
insertion of a software component to the vault wherein 
the post controller generates a unique key from the new 
component and optimizes storage if the unique key 
exists. 

2. A computer-implemented vault for archiving software 
components, where only a single instance of each compo- 
nent that is multiply-used is stored in the vault, comprising: 

unique instances of the one or more software components; 

an access controller for performing a direct, random 
access retrieval of the one or more software compo- 
nents from the vault; and 

a client coupled to the vault, the client having a physical 
software component residing on the client, the client 
generating a key from the physical software compo- 
nent. 

3. A computer-implemented vault for archiving software 
components, where only a single instance of each compo- 
nent that is multiply -used is stored in the vault, comprising: 

unique instances of the one or more software components; 

an access controller for performing a direct, random 
access retrieval of the one or more software compo- 
nents from the vault; 

one or more secondary vaults coupled to the vault; and 

a fault-tolerant rollover system for sequentially searching 
each vault for the presence of a target software com- 
ponent. 
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4. The computer-implemented vault of claim 3, wherein 
the secondary vaults are ordered based on accessibility of 
the vaults. 

5. The computer- implemented vault of claim 3, further 
5 comprising a client for generating a key, the client applying 

the key to recover the target software component from the 
most accessible of the vaults. 

6. The computer-implemented vault of claim 5, wherein 
the client uses a metadata description to generate the key. 

10 7. The computer-implemented vault of claim 5, wherein 
the search of a determined vault fails to locate the target 
software component, and wherein the client skips the deter- 
mined vault and modifies the search order of the vaults in 
recovering the target software component. 

15 8. A computer-implemented vault for archiving software 
components, where only a single instance of each compo- 
nent that is multiply-used is stored in the vault, comprising: 
means for storing unique instances of the one or more 
software components on the vault; 

20 access means for performing a direct, random access 
retrieval of the one or more software components from 
the vault; and 

a post means for performing a direct, random access 
25 insertion of a software component to the vault wherein 
the post means generates a unique key from the new 
component and optimizes storage if the unique key 
exists. 

9. A computer-implemented vault for archiving software 
30 components, where only a single instance of each compo- 
nent that is multiply-used is stored in the vault, comprising: 

means for storing unique instances of the one or more 

software components on the vault; 
access means for performing a direct, random access 
35 retrieval of the one or more software components from 

the vault; and 

a client coupled to the vault, the client having a physical 
software component residing on the client, the client 
generating a key from the physical software compo- 
40 nent. 

10. A computer-implemented vault for archiving software 
components, where only a single instance of each compo- 
nent that is multiply-used is stored in the vault, comprising: 

means for storing unique instances of the one or more 
45 software components on the vault; 

access means for performing a direct, random access 
retrieval of the one or more software components from 
the vault; 

50 one or more secondary vaults coupled to the vault; and 
means for sequentially searching each vault for the pres- 
ence of a target software component. 

11. The computer-implemented vault of claim 10, wherein 
the secondary vaults are ordered based on accessibility of 

55 the vaults. 

12. The computer-implemented vault of claim 10, further 
comprising a client for generating a key, the client having a 
means for applying the key to recover the target software 
component from the most accessible of the vaults. 

60 13. The computer-implemented vault of claim 12, 
wherein the client uses a metadata description to generate 
the key. 

14. The computer-implemented vault of claim 12, 
wherein the search of a determined vault fails to locate the 
65 target software component, and wherein the client skips the 
determined vault and modifies the search order of the vaults 
in recovering the target software component. 
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15. A method for archiving software components where 
only a single instance of each component that is multiply- 
used is stored in a vault, comprising the steps of: 

storing unique instances of the one or more software 
components in the vault; and 5 

performing a direct, random access retrieval of the one or 
more software components from the vault; and 

performing a direct, random access insertion of a software 
component to the vault wherein said step of performing Q 
an insertion generates a unique key from the new 
component and optimizes storage if the key exists, 

16. A method for archiving software components where 
only a single instance of each component that is multiply- 
used is stored in a vault, comprising the steps of: 5 

storing unique instances of the one or more software 

components in the vault; 
performing a direct, random access retrieval of the one or 

more software components from the vault; and 
generating a key from a physical software component 20 

residing on a client coupled to the vault. 

17. A method for archiving software components where 
only a single instance of each component that is multiply- 
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used is stored in a vault, and wherein one or more secondary 
vaults are coupled to the vault, comprising the steps of: 
storing unique instances of the one or more software 

components in the vault; and 
performing a direct, random access retrieval of the one or 

more software components from the vault; and 
sequentially searching each vault for the presence of a 
target software component. 

18. The method of claim 17, wherein the secondary vaults 
are ordered based on accessibility of the vaults, 

19. The method of claim 12, further comprising a client 
for generating a key, the client applying the key to recover 
the target software component from the most accessible of 
the vaults. 

20. The method of claim 19, wherein the client uses a 
metadata description to generate the key. 

21. The method of claim 19, wherein the search of a 
determined vault fails to locate the target software 
component, and wherein the client skips the determined 
vault and modifies the search order of the vaults in recov- 
ering the target software component. 

* * * * * 
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